pp108 : Role Multitenancy Support

Role Multitenancy Support

Process Platform provides multitenancy support for roles, which makes it possible to deploy packages with roles in the Organization space. Roles can be deployed either in the Shared space or Organization space. Users can have roles assigned from both levels, and also roles can be subroles of other roles at both levels. Role multitenancy provides role functionality without deployment restrictions.

Deployment 

There are no restrictions on the deployment of packages, which contain roles. Package roles can be deployed to either the Shared space or Organization space.

You can also use the User Manager to create roles. Such roles are called Organization roles. Package roles deployed to an organization are different from Organization roles. 

The Publish to Runtime feature is available in Collaborative Workspace (CWS) to publish roles to the run time. Publishing a role from CWS currently creates an Organization role and not a Package role.
The multitenancy behavior of roles applies to Package roles only, which are roles deployed through package deployment. Multitenancy behavior does not apply to those roles created by a user in either User Manager or through the Publish to Runtime feature in CWS.

Refer to Managing Application Packages in the Organization Space for information on how to deploy packages in the Organization space.

Runtime 

There is no visible difference between a role deployed to the Shared space or Organization space as the deployment does not change the role definition. The Role DN is the same for a role deployed to both spaces. While using a role anywhere in an application, you cannot specify the space of the role.

For example, consider a scenario where a role is deployed to the Organization space. You cannot view this in a user interface such as User Manager. When the same role is deployed to both the Shared space and Organization space, the User Manager will display only one entry for the role.

Role evaluation is always done by first looking in the Organization space and then in the Shared space.

For example, consider a scenario where a role in the Shared space blocks access to a specific Web service, and an updated version of that same role is deployed to the Organization space where it provides access to the same Web service. In this scenario, the role provides access to the Web service only in the specific organization, but in other organizations, access to the Web service is blocked.

If the same role is deployed in both the Shared space and Organization space, but with different access control definitions, then when evaluating the access control, the role deployed in the Organization space is used. Roles and corresponding Access Control Lists (ACL) are evaluated by first using the Organization space version, and if not present, the Shared space version is used.